xen: credit2: improve debug dump output.
authorDario Faggioli <dario.faggioli@citrix.com>
Wed, 18 Jan 2017 01:10:14 +0000 (02:10 +0100)
committerGeorge Dunlap <george.dunlap@citrix.com>
Wed, 1 Feb 2017 14:31:58 +0000 (14:31 +0000)
commit3af86727b8204eee3ba8b280fb4815d21e0f86f1
treef980c8c3865557e20a1896e8812ff87e30867f4f
parent9d3226aa060916f21df3be98abb39f11496ab8ce
xen: credit2: improve debug dump output.

Scheduling information debug dump for Credit2 is hard
to read as it contains the same information repeated
multiple time in different ways.

In fact, in Credit2, CPUs are grouped in runqueus. Before
this change, for each CPU, we were printing the while
content of the runqueue, as shown below:

 CPU[00]  sibling=000003, core=0000ff
    run: [32767.0] flags=0 cpu=0 credit=-1073741824 [w=0] load=0 (~0%)
      1: [0.0] flags=0 cpu=2 credit=3860932 [w=256] load=262144 (~100%)
      2: [0.1] flags=0 cpu=2 credit=3859906 [w=256] load=262144 (~100%)
 CPU[01]  sibling=000003, core=0000ff
    run: [32767.1] flags=0 cpu=1 credit=-1073741824 [w=0] load=0 (~0%)
      1: [0.0] flags=0 cpu=2 credit=2859840 [w=256] load=262144 (~100%)
      2: [0.3] flags=0 cpu=2 credit=-17466062 [w=256] load=262144 (~100%)
 CPU[02]  sibling=00000c, core=0000ff
    run: [0.0] flags=2 cpu=2 credit=1858628 [w=256] load=262144 (~100%)
      1: [0.3] flags=0 cpu=2 credit=-17466062 [w=256] load=262144 (~100%)
      2: [0.1] flags=0 cpu=2 credit=-23957055 [w=256] load=262144 (~100%)
 CPU[03]  sibling=00000c, core=0000ff
    run: [32767.3] flags=0 cpu=3 credit=-1073741824 [w=0] load=0 (~0%)
      1: [0.1] flags=0 cpu=2 credit=-3957055 [w=256] load=262144 (~100%)
      2: [0.0] flags=0 cpu=2 credit=-6216254 [w=256] load=262144 (~100%)
 CPU[04]  sibling=000030, core=0000ff
    run: [32767.4] flags=0 cpu=4 credit=-1073741824 [w=0] load=0 (~0%)
      1: [0.1] flags=0 cpu=2 credit=3782667 [w=256] load=262144 (~100%)
      2: [0.3] flags=0 cpu=2 credit=-16287483 [w=256] load=262144 (~100%)

As it can be seen, all the CPUs print the whole content
of the runqueue they belong to, at the time of their
sampling, and this is cumbersome and hard to interpret!

In new output format we print, for each CPU, only the vCPU
that is running there (if that's not the idle vCPU, in which
case, nothing is printed), while the runqueues content
is printed only once, in a dedicated section.

An example:

 CPUs info:
 CPU[02]  runq=0, sibling=00000c, core=0000ff
    run: [0.3] flags=2 cpu=2 credit=8054391 [w=256] load=262144 (~100%)
 CPU[14]  runq=1, sibling=00c000, core=00ff00
    run: [0.4] flags=2 cpu=14 credit=8771420 [w=256] load=262144 (~100%)
 ... ... ... ... ... ... ... ... ...
 Runqueue info:
 runqueue 0:
      0: [0.1] flags=0 cpu=2 credit=7869771 [w=256] load=262144 (~100%)
      1: [0.0] flags=0 cpu=2 credit=7709649 [w=256] load=262144 (~100%)
 runqueue 1:
      0: [0.5] flags=0 cpu=14 credit=-1188 [w=256] load=262144 (~100%)

Note that there still is risk of inconsistency between
what is printed in the 'Runqueue info:' and in 'CPUs info:'
sections. That is unavoidable, as the relevant locks are
released and re-acquired, around each single operation.

At least, the inconsistency is less severe than before.

Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-by: George Dunlap <george.dunlap@citrix.com>
xen/common/sched_credit2.c
xen/common/schedule.c